Microsoft Intune Connector for Active Directory security update
Updated 04/18/25: Based on customer feedback around challenges with setting up the connector with build 6.2501.2000.5, we have released an updated build with improved functionality and updated our troubleshooting documentation with more guidance on avoiding configuration issues in your environment. The new build 6.2504.2001.8 is available for download in Microsoft Intune. New in build 6.2504.2001.8: The sign in page in the wizard now uses WebView2, built on Microsoft Edge, instead of the previously used WebBrowser. Error "MSA account <accountName> is not valid" which some customers reported during sign in has been fixed. As part of Microsoft’s Secure Future Initiative, we’re making an important security change which will impact customers deploying Microsoft Entra hybrid joined devices with Windows Autopilot and provide guidance on how to prepare. New capabilities or improvements aren’t planned as part of this security change. Review Microsoft’s recommendations based on your organization’s needs. Updated connector Today, Windows Autopilot uses the Intune Connector for Active Directory to deploy devices that are Microsoft Entra hybrid joined. To strengthen security in our customers’ environments, we’ve updated the Intune Connector for Active Directory to use a Managed Service Account (MSA) instead of a SYSTEM account. The old connector which uses the local SYSTEM account will no longer be available for download in Intune and will stop being supported in late June 2025. At that point, we’ll stop accepting enrollments from the old connector build. Follow the guidance provided below to update your environment to the new connector. The old connector build will continue to work for existing customers who already have it installed until the end of support date and is available for download in the Microsoft Download Center if needed. What is a Managed Service Account (MSA)? MSAs are managed domain accounts that have automatic password management and are generally granted just enough permissions and privileges to perform their duties. Standalone MSAs can only be used on a single domain joined machine and can only access resources within that domain. An MSA can run services on a computer in a secure and easy to maintain manner, while maintaining the capability to connect to network resources as a specific user principal. All these reasons make them a better fit for the Intune Connector for Active Directory than the current SYSTEM account option. Comparing the account permissions required between the new and old connector Old Connector New Connector Logged on account SYSTEM Domain\MSA Password management Set by user, subject to domain rules Managed by domain only – automatically reset Privilege set size (see notes for more details) MAX 5 Privileges: SeMachineAccountPrivilege - Disabled default SeChangeNotifyPrivilege - Enabled Default SeImpersonatePrivilege - Enabled Default SeCreateGlobalPrivilege - Enabled Default SeIncreaseWorkingSetPrivilege – Disabled default Registry access rights Full, implicit Read write, explicit Enrollment certificate rights Full, implicit Full, explicit Create computer object rights (required for hybrid Autopilot scenario) If connector is on the same machine as domain controller, unlimited If connector is not on the domain controller, delegation required Explicit delegation required Setting up the connector Before you begin First, you need to uninstall the existing connector by: Uninstalling from the Settings app on Windows Then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). To install and set up the new connector, you need the following minimum requirements: Downloading the connector build from Intune: Microsoft Entra account with Intune Service Administrator permissions Installation: .Net 4.7.2 Windows Server with 2008 R2 functional level Local administrator permissions Setting up the connector: Microsoft Entra account with an Intune license assigned and Intune Service Administrator permission Domain account with local administrator privileges Domain account should have permission to create msDS-ManagedServiceAccount objects Downloading the connector You can download the new connector from the Intune admin center and install in your environment. To set it up, launch the connector wizard and choose Sign In and sign in with a Microsoft Entra account with Intune service admin permissions and you’ll notice a new Configure Managed Service Account option. After signing in, the connector will enroll and only the Configure Managed Service Account option will be available. The account with Intune admin permissions should select that option to complete set up. For more detailed steps on installing the connector, review: Install the Intune Connector. Configuring organizational units (OUs) for domain join By default, MSAs don’t have access to create computer objects in any OU. If you wish to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. This can be done at any time (either before enrollment, or after the connector is enrolled): Update ODJConnectorEnrollmentWizard.exe.config: Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard” Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin OU name should be the distinguished name (see Additional information section) Note that the MSA is only granted access to the OUs configured in this file (and the default Computers container). If any OUs are removed from this list, completing the rest of the steps will revoke access. Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button. Success! – A pop up will appear showing success. Using the Intune Connector with multiple domains Customers who are already using the connector with more than one domain will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain. Configuring the connector The Intune Connector for Active Directory needs to be installed on each domain that you plan to use for domain join. If you need to have a second account redundancy, you will need to install the connector on a different server (in the same domain). Follow the steps above to ensure the connector is configured correctly, and that the MSA has appropriate permissions on the desired OUs. Ensure that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5: A list of Intune Connectors for Active Directory and their version in the Microsoft Intune admin center. Configure Domain Join profile: Follow the steps for configuring a domain join profile: Create a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot. Target the domain join profile to the appropriate device groups. Example of 2 domain join profiles targeted to different groups, with different domain names configured: Expected result: Connector in domain F11.F1.com will only join domain F11.F1.com. Connector in domain F12.F1.com will only join domain F12.F1.com. Additional information Retrieving Organizational Unit Distinguished Name If you need to customize the OUs that the MSA has access to, here are two easy methods to retrieve the distinguished name for these OUs: Let’s assume we have the following structure: Powershell Get-ADOrganizationalUnit (ActiveDirectory) | Microsoft Learn Get “=TestOUWithSpecialChars=”: PS Cmd: Get-ADOrganizationalUnit -Filter 'Name -like "*TestOUWithSpecialChar*"' | Format-Table Name, DistinguishedName Output: “OU=\=TestOUWithSpecialChars\=,DC=modesh2,DC=nttest,DC=microsoft,DC=com” Note, ‘=’ is escaped Get “NestedOU” PS Cmd: Get-ADOrganizationalUnit -Filter 'Name -like "NestedOU"' | Format-Table Name, DistinguishedName Output: “OU=NestedOU,OU=\=TestOUWithSpecialChars\=,DC=modesh2,DC=nttest,DC=microsoft,DC=com” Note, ‘=’ is still escaped Active Directory Users and Computers Select “View” from the menu, and enable “Advanced Features” Right click on the specific OU and click “Properties” Navigate to the “Attribute Editor” tab Select “distinguishedName” attribute and click “View” Summary The new connector aims to enhance security by reducing unnecessary privileges and permissions associated with the local SYSTEM account. This blog describes how to set up the new connector and configure it for your organization. Make sure to install the new connector by late June 2025 before the old connector becomes unsupported. If you have any questions, leave a comment on this post or reach out to us on X @IntuneSuppTeam. Post updates: 04/18/25: Updated post with a note on our release of our latest build, version 6.2504.2001.8, improving user experience and system performance. Supportability for the old connector has also been updated to June 2025 (previously May).Debunking the myth: Cloud-native Windows devices and access to on-premises resources
By: Roger Southgate - Sr. Product Manager | Microsoft Intune Myth vs reality Myth: Cloud-native Windows devices can’t access on-premises resources such as file shares or legacy applications. Reality: With minimal or no configuration, cloud-native devices can seamlessly access on-premises resources using NTLM or Kerberos. Introduction Microsoft’s vision for secure, productive workplaces is clear: adopt cloud-first services, integrate Zero Trust throughout, and deploy Windows 11 devices as cloud-native endpoints to stay agile and future-ready. If you’re yet to begin this journey, review the Set up and configure a cloud-native Windows endpoint with Microsoft Intune tutorial. For context, a cloud-native device is a Windows device, joined to Microsoft Entra and managed by Intune. No domain join, no group policy, and no Microsoft Configuration Manager required. Leveraging complementary services such as Windows Autopilot and Windows Autopatch enables users to self-provision their devices, work remotely, and remain secure by applying the latest Windows Updates. But what about user’s data, files, and applications that they require to be productive? Moving to the cloud is a common goal for many organizations, though practical realities can make this a gradual process. Legacy technology, operational constraints, complexity, and other challenges can hinder adoption. While the goal might be to migrate all data to cloud-friendly repositories such as SharePoint Online and OneDrive, and transition applications to SaaS solutions, these migrations don’t happen overnight. In many cases, data may remain scattered across internal servers and on-premises repositories, creating scenarios where cloud-native devices still need to connect to these resources. Accessing on-premises resources What happens when you take a cloud-native device and try to access an on-premises resource such as a file share? Similarly, what about access to an application that is located on-premises? While these are just two examples, they can be used interchangeably in this scenario since the process of getting access is the same, regardless of apps or files. This is a topic that is raised (and often misunderstood) when discussing the transition of Windows devices to the cloud. Cloud-native devices were designed to take this scenario into account and have seamless access to on-premises resources. Note: This assumes you have line-of-sight to an Active Directory Domain Controller and that your on-premises resources, such as file shares and applications, use Windows authentication. Like a domain-joined device, a cloud-native device won’t have line of sight by default unless it’s physically on-site (for example, in a corporate office). If you require this functionality, you may need to use a VPN or Zero Trust Network Access (ZTNA) solution to provide this connectivity to on-premises resources. More on this later, when we touch on Microsoft Entra Global Secure Access. Legacy applications and authentication When people talk about legacy applications in this context, they typically mean apps that can only do legacy (NTLM or Kerberos) authentication with Active Directory. The good news is that for users synchronized using Microsoft Entra Connect Sync, cloud-native devices can seamlessly authenticate using NTLM and Kerberos just like domain-joined devices. When an on-premises domain account is synchronized to Microsoft Entra ID via Microsoft Entra Connect Sync, Windows uses details from Microsoft Entra ID, such as the source Active Directory domain name and the user’s User Principal Name (UPN), to locate a Domain Controller the same way an Active Directory domain-joined device does. If the user has signed into Windows using a password, Windows sends the on-premises domain information and user credentials to the Domain Controller to obtain a Kerberos Ticket-Granting Ticket (TGT) or NTLM token, based on the protocol the on-premises resource or application supports. From that point onwards, the TGT is used to get session keys that grant access to resources. Refer to How SSO to on-premises resources works on Microsoft Entra joined devices for additional details on how this process works. Note: Windows 11, version 24H2 and later releases have removed the NTLMv1 protocol as part of Microsoft's broader initiative to phase out NTLM. Refer to the Microsoft support article on Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 for additional details. Windows Hello for Business Passwordless authentication mechanisms such as FIDO2 and Windows Hello for Business are a cornerstone of Microsoft’s security vision. Adopting these authentication methods delivers stronger security and better, simpler user experiences. Windows Hello for Business provides phishing-resistant credentials as required by some security guidelines such as the Australian Cyber Security Centre ‘Essential Eight’. If you’re not already doing so, deploying cloud-native devices is a great opportunity to start using Windows Hello for Business, especially since it’s enabled by default on these devices. Windows Hello for Business is also a feature which results in a win-win scenario by enhancing security for IT, while also improving the user experience. While enabling Windows Hello for Business is a simple process, there’s some additional configuration required to enable single sign-on to on-premises Active Directory authenticated resources, and this is where we sometimes see customers running into issues. If username and password work successfully to access an on-premises resource, but Windows Hello for Business credentials don’t then ensure that you’ve setup Cloud Kerberos trust to enable single sign-on. Cloud Kerberos Trust removes much of the complexity once associated with configuring Windows Hello for Business, greatly simplifying the deployment process. When signing in with Windows Hello for Business, the device uses a partial Kerberos TGT issued by Microsoft Entra ID to obtain a full TGT from Active Directory, which in turn is used to get session keys to access resources. Refer to Microsoft Entra join authentication to Active Directory using cloud Kerberos trust for additional details. Zero Trust and modern connectivity On your Zero Trust journey, if you need to provide access to on-premises applications and services, consider replacing your traditional VPN with a modern solution, enabled by Microsoft Entra Private Access. Doing so will help you ensure secure, fine-grained access to private applications and resources, without exposing your full network - aligned with Microsoft’s three Zero Trust principles: verify explicitly, enforce least privilege, and assume breach. Review Zero Trust and Cloud-Native Windows for a deeper dive into this topic. On the subject of Zero Trust, did you know that Microsoft has developed a Zero Trust Workshop? By adopting Zero Trust, your organization can enhance its security posture and reduce risk and complexity while improving compliance and governance. Navigating the complexities of modern security is challenging and a Zero Trust strategy is the first step in providing clarity and direction. The Zero Trust Workshop is a guided framework to help you translate your Zero Trust strategy into actionable implementation steps which track your deployment progress and align with Microsoft recommendations. We’ve had many customers leverage the workshop to supercharge their Zero Trust journey and realize the full value of their existing security investments. The workshop can be run self-guided or in collaboration with your Microsoft account team or a partner and is vendor agnostic. Key takeaways If you aren’t already provisioning new Windows devices as cloud-native, check out Set up and configure a cloud-native Windows endpoint with Microsoft Intune and Cloud-native Windows endpoints: Begin by beginning to get started with a cloud-native Windows proof of concept today. Cloud-native doesn’t mean cloud only, these devices get the benefits of being cloud-first while maintaining the backward compatibility needed to access on-premises resources when necessary. Modern identity solutions such as Microsoft Entra ID, Windows Hello for Business, and Zero Trust Network Access can simultaneously enhance security and user experience. Be sure to check out our Zero Trust Workshop to help you plan and implement these and other technologies as part of your Zero Trust strategy. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Configure the new Microsoft Intune connector for Active Directory with the least privilege principle
By: Arpit Sinha | Support Escalation Engineer – Microsoft Intune The purpose of the Microsoft Intune Connector for Active Directory, also known as the Offline Domain Join (ODJ) Connector, is to join computers to an on-premises domain during the Windows Autopilot process with the device ultimately becoming Microsoft Entra hybrid joined after the user logs into the device for the first time. The Intune Connector for Active Directory creates computer objects in a specified Organizational Unit (OU) in Active Directory during the domain join process. Important Note: Although fully supported, performing hybrid join during Windows Autopilot isn’t recommended as it can be difficult to configure, troubleshoot, and support over time. For additional information on this topic refer to Join your cloud-native endpoints to Microsoft Entra and the blog, Success with remote Windows Autopilot and hybrid Azure Active Directory join. Earlier this year, Intune released an updated Intune Connector for Active Directory that strengthens security and follows least privilege principles by using a Managed Service Account (MSA). As communicated in both the blog and Message Center, as started in July 2025, older versions of the connector will cease to operate successfully. Below are the useful steps you should follow while configuring the updated Intune Connector for Active Directory: Sign in to the Intune Connector for Active Directory Verify the Intune Connector for Active Directory is active Configure the MSA to allow creating objects in OUs (optional) Error when granting permissions to MSA account An issue that a small number of customers may experience during the connector installation is the inability for the installation process to grant the MSA account the necessary permissions on the default computers container or a specific organizational unit. The below screenshot shows the error message displayed when you encounter this error during installation. The installation log is named odjconnectorUI.txt, located in C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard, and shows the following when you encounter this error: Unknown error: System.DirectoryServices.DirectoryServicesCOMException (0x8007202F): A constraint violation occurred. Workaround and walk through To workaround the above issue, the following is a walkthrough for successfully installing the connector and the steps required to handle the MSA permission error. Follow the Install the Intune Connector for Active Directory on the server guidance to setup the new ODJ connector. You need to initiate the installation with an account that has the following rights: Create msDs-ManagedServiceAccount objects in the Managed Service Accounts container (domain rights) Local administrator on your Windows Server After successful installation and Microsoft Entra sign in (using an Intune Admin or Global Admin account), you’ll get the below confirmation screen in the Intune Connector for Active Directory showing that the connector is successfully enrolled and that an MSA account was successfully created. After selecting on ‘Ok’ in the above confirmation screen, wait a few seconds, and you might receive the error that mentions the MSA account 'could not be granted permission' and will show the MSA name which was created as highlighted in the below screenshot. Note the name of the MSA account as this is needed in a below step. Note: If setup is complete and successful, it won’t throw the above error. If the dialog is closed, go to location ‘C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard’ and relaunch ‘ODJConnectorEnrollmentWizard.exe’. Verify that the connector installation successfully created the MSA in Manager Service Account container in the Active Directory User and Computers console. Note that you must enable Advanced Features in the View menu to show this container. Validate that the 'Intune ODJ connector service' is Running with an Automatic Startup Type and with 'Log on As' use the MSA account configured during the connector’s installation only. As shown in the following example screenshot. Verify in the Intune admin center under Device > Enrollment > Intune Connector for Active Directory that the connector is Active. Note: Inactive connectors in the Intune Connector for Active Directory page will automatically be cleaned up after 30 days. Grant the Create Computer objects permission to the MSA account created by the connector installation on the organization unit or container that you configured the connector to use. This is best done using the Delegation of Control Wizard in the Active Directory User and Computers console. The following screenshot shows the end result. Note: Selecting ‘Configure Managed Service Account’ again will still result in the same permissions error. This is a known issue that can be ignored and will be addressed in the next released build of the connector.You can now proceed with provisioning devices using Autopilot. Look for the following event log events in Event Viewer on the server hosting the connector to validate correct functionality: Event Log Event Application and Services Logs > Microsoft > Intune > ODJConnectorService > Admin Event ID 30120 (successful Event) Application and Services Logs > Microsoft > Intune > ODJConnectorService > Operational Event ID 30130 and 30140 (successful Events) Summary Ensure that you’ve updated to the new connector as old versions will stop working. Additionally, ensure that the Managed Service Account has the correct permissions on the designated organizational unit. This is essential for the smooth operation of the Intune Connector for Active Directory. While you may encounter an error when selecting "Configure Managed Service Account", this can typically be safely ignored during initial setup. To confirm that the connector is functioning correctly and that devices can be provisioned through Autopilot without issues, monitor the event logs under the Intune ODJConnectorService. These logs provide critical insight into the provisioning process and helps validate successful connector enrollment and operation. Related information: Enrollment for Microsoft Entra hybrid joined devices Plan for Change: New Intune connector for deploying Microsoft Entra hybrid joined devices using Windows Autopilot Microsoft Intune Connector for Active Directory security update If you have any questions or want to share how you’re managing your Windows Autopilot devices with Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn.
